Subject: DLSw Multicast Version 1.0 Proposal

From: [email-masked]
Date: 19 Oct 95 11:07:10 EDT

David Bryant 3Com Corp                                    October 1995
Mike Redden  Proteon Inc                                

DLSw Multicast Protocol Enhancements

1. Background 
2. Intent 
3. Scope 
4. Overview 
5. Capabilities Exchange 
6. Multicast Groups and Addressing 
6.1 Using Multicast Groups 
6.1.1 SNA Client/Server groups 
6.1.2 NetBIOS groups 
6.1.3 Mixed Groups 
7. DLSw Message Transports 
7.1 TCP/IP Connections 
7.2 UDP Datagrams 
7.3 Multicast Datagrams 
8. SNA Support 
8.1 Address Resolution 
8.2 Circuit Setup 
8.3 Multicast Reliability 
8.3.1 Retries 
9. NetBIOS 
9.1 NetBIOS Remote Name Directory Support 
9.2 Address Resolution 
9.3 Circuit Setup 
9.4 Multicast Reliability and Retries 
10. Sequencing 
11. Migration 
11.1 Connecting to downlevel nodes 
11.2 Communicating with downlevel nodes 
12. SSP Frame Formats 
12.1 Multicast Capabilities Control Vector 
12.2 Multicast Packets 
12.3 UDP Packets 

Background

RFC 1795 specifies an AIW standard for the Switch to Switch Protocol (SSP) of 
Data Link Switching (DLSw).   Through implementation and installation 
experiences, vendors have become increasingly more concerned with the 
scalability of the DLSw protocols in large networking situations.  Accordingly, 
a DLSw Scalability group has been established within the AIW to define a set of 
DLSw protocol enhancements for the purpose of improving DLSw scalability. 

It is assumed that the reader is familiar with DLSw and RFC 1795.  No effort 
has been made to explain those protocols or associated terminology.  Note: 
Throughout this document the acronym SSP has been used interchangeably to refer 
to both the switch to switch protocol of DLSw and the set state machines which 
implement the protocol.  Consequently, the endpoint of an SSP message exchange 
is often referred to as an SSP.

Intent

This document defines a set of SSP protocol enhancements to RFC 1795 which will 
improve the scalability of DLSw.  These enhancements are designed to be fully 
backward compatible with existing  RFC 1795 implementations.   Once completed 
and approved within the AIW, it is the intent of the DLSw Scalability group  to 
submit these enhancements to the IETF in the form of an informational RFC.  As 
a compatible set of enhancements to RFC 1795, this document does not replace or 
supersede RFC 1795. 

Scope

The DLSw Scalability group of the AIW has identified a number of scalability 
issues associated with existing DLSw protocols as defined in RFC 1795: 

z Administration
 
 RFC 1795 implies the need to define the transport address of all peer SSPs at 
each SSP.  In highly meshed situations (such as those often found in NetBIOS 
networks), the resultant administrative burden is undesirable.
 
z Address Resolution
 
 RFC 1795 defines point to point TCP (or other reliable transport protocol) 
connections between each SSP.  When attempting to discover the location of an 
unknown resource, an SSP sends an address resolution packet to each partner SSP 
over these connections.  In highly meshed configurations, this can result in a 
very large number of packets in the transport network.  Although each packet is 
sent individually to each SSP partner, they are each identical in nature.  Thus 
the transport network is burdened with excessive numbers of identical packets.  
Since the transport network is most commonly a wide area network where 
bandwidth is considered a precious resource, this packet duplication is 
undesirable. 

z Broadcast Packets
 
 In addition to the address resolution packets described above, RFC 1795 also 
propagates NetBIOS broadcast packets into the transport network.  The UI frames 
of NetBIOS are sent as LAN broadcast packets and RFC 1795  SSPs propagate these 
packets over the point to point transport connections to each SSP partner.  In 
the same manner as above, this creates a large number of identical packets in 
the transport network.  This is also considered undesirable.  And because 
NetBIOS UI frames can be sent by applications, it is difficult to predict or 
control the rate and quantity of such traffic.   This compounds the 
undesirability of the existing RFC 1795 propagation method for these packets.
 
z TCP (transport connection) Overhead
 
 As defined in RFC 1795, each SSP maintains a transport connection to its peer 
SSP partners.  Each transport connection guarantees in order packet  
delivery.   This is accomplished using acknowledgment and sequencing algorithms 
which require both CPU and memory at the SSP endpoints in direct proportion to 
the number transport connections.   The DLSw Scalability group has identified 
two scenarios where the number of transport connections can become significant 
resulting in excessive overhead and corresponding equipment costs (in memory 
and CPU).   The first scenario is found in highly meshed SSP configurations 
where the number of transport connections approximates n2 (where n is the 
number of SSPs).  This is typically found in DLSw networks supporting NetBIOS.  
The second scenario is found  in networks  where many remote locations 
communicate to few central sites. 
 In this case, the central sites must support n transport connections  (where n 
is the number of remote sites).    In both scenarios the resultant transport 
connection overhead is considered undesirable depending upon the value of n.   

z LLC2 overhead

RFC 1795 specifies that each SSP provides local termination for the LLC2 (SDLC 
or other SNA reliable data link  protocol) sessions traversing the SSP.   
Because these reliable data links also provide guaranteed in order packet 
delivery, the memory and CPU overhead of  maintaining these connections can 
also become significant.   This is particularly undesirable in the second 
scenario described above.  This is because the number of reliable connections 
maintained at the central site is the aggregate of the connections maintained 
at each remote site.  

It is not the intent of this document to address all the undesirable 
scalability issues associated with RFC 1795.   This paper identifies protocol 
enhancements to RFC 1795 using the inherent multicast capabilities of the 
underlying transport network to improve the scalability of RFC 1795.   It is 
believed that the enhancements defined will address many of the issues 
identified such as: administration, address resolution,  broadcast packets, and 
to a lesser extent transport overhead.   This paper will not address LLC2 
overhead.   Subsequent efforts by the AIW and/or DLSw Scalability group may 
address the unresolved scalability issues.

In addition, it is recognized that not all transport protocols applicable to 
DLSw will provide multicast services.  Since TCP is the most prevalent 
transport protocol in use today, the DLSw Scalability group has chosen to focus 
its definition around TCP based multicast services and address any other 
protocols as the need may arise in the future. 

Overview

This paper will describe the use of multicast services within the transport 
network to improve the scalability of DLSw based networking.   There are only a 
few main components of this proposal:

z Single session TCP connections
 
 RFC 1795 defines a negotiation protocol for SSPs to use either two 
unidirectional or one bi-directional TCP connection.    SSPs implementing these 
enhancements must endeavor to negotiate for one bi-directional TCP connection.  
Negotiation to two unidirectional TCP connections is only supported for 
migration purposes when communicating with SSPs that do not implement these 
enhancements. 
 
z TCP connections on demand
 
 SSPs will only establish a TCP connection when necessary.  SSP connections to 
SSPs which do not implement this enhancement are assumed to be established by 
means defined outside this paper.  SSPs implementing this enhancement utilize 
multicast services to send address resolution packets (CANUREACH_ex, 
NETBIOS_NQ_ex, etc.).  If a positive response is received, then a TCP 
connection is only established to the associated SSP peer if one does not 
already exist.  Correspondingly, TCP connections are brought down when there 
are no circuits to a partner SSP for an implementation defined period of time. 
   
z Address resolution through multicast and UDP
 
 As described above, multicast services in the transport network are used to 
propagate address resolution packets.   This avoids the need to maintain TCP 
SSP connections between when no circuits are active.  In addition, most 
multicast services (including TCPs MOSPF, DVMRP, MIP, etc.) replicate and 
propagate messages only as necessary to deliver to all multicast members.   
This avoids duplication and excessive bandwidth consumption in the transport 
network.  
 
 To further optimize the use of WAN resources, address resolution responses are 
sent in a directed fashion via UDP transport.   This avoids the need to setup 
or maintain TCP connections when they are not required.  It also avoids the 
bandwidth costs associated with broadcasting.   
 
z NetBIOS broadcasts over multicast and UDP

In the same manner as above, NetBIOS broadcast packets (as defined by  the 
broadcast bit in the 
outing control field) are sent over the transport multicast services.  This 
avoids the need to establish TCP connections between SSPs when there are no 
circuits required.   In addition, bandwidth in the transport network is 
conserved by utilizing the efficiencies inherent to multicast service 
implementation.

Capabilities Exchange

In order to guarantee both backward and forward capability, SSPs which 
implement multicast enhancements will carry a Multicast Capabilities Control 
Vector in their capabilities exchange.   Presence of the Multicast Capabilities 
control vector indicates support for the protocols defined in this document.  
Conversely, lack of the Multicast Capabilities control vector indicates no 
support for these extensions.    

The Multicast Capabilities control vector contains the following fields:

z Version Number

A one byte binary numeric identifier of the Multicast support capabilities.   
Implementations corresponding to this specification will carry a binary value 
of  x01. 

Multicast Groups and Addressing 

In order to accommodate logical network separation, multiple multicast address 
groups are allowed.   To further optimize address resolution protocols, 
multicast groups can be defined in two ways: Client/Server and Peer to Peer.   
There are 64 client/server multicast groups and 127 peer to peer multicast 
groups.  Roughly speaking the two multicast group types correspond to the two 
predominant network configurations represented by SNA and NetBIOS.   SNA 
networks are largely Client/Server oriented in that many remote sites (clients) 
require access to a small number of central sites (servers).  But direct 
communications between remote sites (client to client) is far less likely.   
NetBIOS networks are largely peer to peer in that NetBIOS protocols require the 
participation of all NetBIOS nodes in many of the protocol exchanges (e.g., 
ADD_NAME_QUERY, etc.).  

Peer to Peer multicast groups are defined by shared use of a single multicast 
address.  All members of the peer to peer group send and receive packets 
to/from the same multicast address.   An individual SSP can be a member of 
multiple peer to peer (and/or client-server groups) at the same time.   Peer to 
Peer multicast group addresses range from 255.0.1.129 to 255.0.1.255. 

Client/Server groups are defined by shared use of two multicast addresses.  
Clients within a group are addressed by one multicast address and servers are 
addressed by the other.   In this way communications can be targeted to either 
clients or servers.   The Client/Server address range is from 255.0.1.1 to 
255.0.1.128.   Within a given Client/Server multicast group the address of the 
client and the server are offset  by 64.   The server address is always 64 
higher than the client address.  To illustrate:  clients in Client/Server 
multicast group 1 will have an address of 255.0.1.1 and servers will have an 
address of 255.0.1.65.  Clients in multicast address group 2 will have an 
address of 255.0.1.2 and servers 255.0.1.66, and so on up to Client/Server 
group 64 where clients have address 255.0.1.64 and servers have address 
255.0.1.128.  

Using Multicast Groups

The multicast addressing as described above can be effectively used to limit 
the amount of broadcast/multicast traffic in the network.  It is not the intent 
of this document to describe how individual DLSw/SSP implementations would 
assign or chose group addresses.   The specifics of how this is done and 
exposed to the end user is an issue for the specific implementor.    In order 
to clarify the concepts, however, a few examples are provided below:

SNA Client/Server groups

In the typical SNA Subarea configuration communications is typically between 
PU2 and Host sites.  That is to say, communications is not sent directly 
between PU2 locations.  In this scenario, it would be useful for SSPs to be 
assigned a single group number and a client or server designation.  Host sites 
would be designated as servers and PU2 sites as clients.  When a test frame is 
received at a client site, it would send out a CANUREACH_ex to the server 
multicast address associated with that group.  This effectively avoids 
searching the other PU2 sites for the host.  In the same way, test frames 
generated at the host site would result in a CANUREACH_ex message being sent to 
the client multicast address of the group.  This avoids searching other host 
sites for the PU2.  

NetBIOS groups

Large interconnected NetBIOS networks can be separated into multiple logical 
and distinct networks through the use of different multicast group numbers.  A 
set of NetBIOS stations/locations in one network can be assigned one group 
number and a different set a different group number.  This effectively 
separates the two networks because address resolution packets will never flow 
from one network to the other.  

Its expected that normally peer group addresses would be used for NetBIOS 
because many of the NetBIOS UI frames must be broadcast to all NetBIOS stations 
in the network regardless of application specifics (e.g., ADD_NAME_QUERY, 
ADD_GROUP_QUERY, etc.).   It is possible, however, to utilize the Client/Server 
addressing mechanisms to specifically target NAME_QUERY flows only to certain 
locations where NetBIOS servers are known to be located.  This provides an 
function much like filtering.

Mixed Groups

In many scenarios, SSPs will be connected to LANs which have both SNA and 
NetBIOS traffic.  In this case DLSw implementations will likely need fairly 
sophisticated means of assigning multicast groups.  
One simple mechanism might be to assign group numbers (and/or Client-Server 
roles) via protocol.  For example.  SNA is Client/Server group 1 and this 
location is a client location.  NetBIOS is Peer to Peer group 129.  The SSP can 
then effectively use the SAP portion of received frames when selecting the 
appropriate multicast address.   

When further granularity is desirable, more complicated mechanisms would be 
required.  For example, if a given SSP is connected to a LAN with both PU2 and 
T2.1 nodes, both Client/Server and Peer to Peer communications is possible.  In 
this case, it may be possible for an SSP to distinguish between groups by 
associating multicast groups to individual nodes via MAC address (or 
equivalent).  

DLSw Message Transports

With the introduction of DLSw Multicast Protocols,  SSP messages are now sent 
over three distinct transport mechanisms:  TCP/IP connections, UDP datagrams, 
and Multicast Datagrams.  

TCP/IP Connections

As is the case in RFC 1795, TCP/IP connections are established between SSPs.  
Unlike RFC 1795, however, TCP/IP connections are only established to carry 
reliable circuit data (i.e., LLC2 based circuits).  
Accordingly, a TCP/IP connection is only established to a given partner SSP 
when the first circuit to that SSP is required.  In addition, the TCP/IP 
connection is brought down an implementation defined amount of time after the 
last circuit has terminated.

UDP Datagrams

Because the address resolution protocols have been moved out of the TCP 
transport network, they are now sent via a combination of multicast and UDP 
transport.    Generically speaking, UDP based transport is utilized whenever an 
SSP message must be sent to a unique SSP.   This is typically the case in 
address resolution responses.   There are, however, some other cases where UDP 
is used to handle directed UI NetBIOS frames such as STATUS_RESPONSE.   Further 
detail is provided  in the NetBIOS section of this document.  

Multicast Datagrams

Multicast datagrams are used to transport all broadcast oriented UI traffic.  
In the case of SNA, this is primarily the CANUREACH_ex packets.  In the case of 
NetBIOS, multicast datagrams are used to send 
all broadcast UI frames.   A more detailed listing can be found in the NetBIOS 
section of this document.  

SNA Support 

SNA protocols fall into two both Client/Server (SSCP/PU) and Peer to Peer (T2.1 
nodes and SSCP to SSCP) configurations.  But in both cases, all communication 
is LLC2 (or LLC2 like) based.  (Note this paper does not attempt to address the 
unique issues presented by SNA/HPR and its non-ERP data links.)   Consequently, 
the generalized packet sequence of interest is a test frame exchange followed 
by an XID exchange.   The following paragraphs describe how multicast protocol 
enhancements are used to establish SNA data links.

Address Resolution

When an SSP receives an incoming test frame from an attached data link, the 
assumption is that this is an exploratory frame in preparation for an XID 
exchange and link activation.  The SSP must determine a correlation between the 
destination LSAP (mac and sap pairing) and some other SSP in the transport 
network.   This paper generically refers to this process as address resolution. 

SSPs use the following algorithm to correlate a given LSAP to some partner SSP 
in the transport network:

/* Begin */

Check the local cache 
 If found 
  Then do I=1 to retry_count
   Send a UDP based CANUREACH_ex is to the corresponding SSP 
   If an ICANREACH_ex is received (within a timeout window)
    then normal circuit setup is initiated
  End do   
             
  Else do I=1 to retry_count
   Send a CANUREACH_ex to the appropriate multicast address
   If an ICANREACH_ex is received (within a timeout window)
          then normal circuit setup is initiated
  End do

/* Otherwise */
Circuit setup fails 

/* End */

Circuit Setup

Circuit setup is accomplished in the same manner as described in RFC 1795.  
More specifically, CANUREACH_cs, ICANREACH_cs, REACH_ACK, XIDFRAME, etc. are 
all sent over the TCP connection to the appropriate SSP.   This, of course, 
assumes the existence of a TCP connection between the SSPs.   If the sending 
SSP (sending a CANREACH_cs ) detects no active TCP connection to the partner 
SSP, then a TCP connection setup is initiated and the packet sent.  All other 
circuit setup (and takedown) related sequences are now passed over the TCP 
connection. 

Multicast Reliability 

It is important to note, that multicast services do not provide a reliable 
means of delivery.  Existing RFC 1795 protocols guaranteed the delivery 
(failure notification) of CANUREACH_ex and ICANREACH_ex messages.  Neither TCP 
multicast or UDP will provide the same level of reliability.  It is therefore 
possible that these messages may be lost in the network.  

Retries 

Test Frames are generally initiated by end stations every few seconds.  Many 
existing DLSw implementations take advantage of the reliable SSP TCP 
connections and filter out test frame retries which a CANUREACH_ex is 
outstanding.   Given the unreliable nature of multicast and UDP transport for 
these messages, this filtering is no longer advisable.  Although the RFC 1795 
specification does not address this issue directly, it would be prudent for 
DLSw implementations to shorten the amount of time test frames are filtered.  
Once this timer has expired, the next test frame should result in a new 
CANUREACH_ex message.   The  filtering time should be shortened to somewhere 
between the end station retry timer and total link activation time (i.e., 
retry_timer < t < retry_timer x retry_count).  This way the originating SSP 
will filter some local test frame retries, but periodically retry the 
CANUREACH_ex process from the originating side.  It is advisable to maintain 
some way of correlating retries to the original message.   This way late 
responses to the original CANUREACH_ex can still be correlated to the 
appropriate link activation attempt.   Note: There is no retry logic associated 
with ICANREACH_ex messages. 

NetBIOS

With the introduction of DLSw Multicast transport, all NetBIOS UI frames are 
carried outside the TCP connections between SSPs (e.g., via UDP and Multicast 
datagrams).   The following table defines the various NetBIOS UI frames and how 
they are transported between SSPs:

   ................................................Transport
Message Event.............Action................Mechanism   
--------------------------------------------------------------------
ADD_GROUP_NAME_QUERY....Send DATAFRAME..........Multicast   
ADD_NAME_QUERY..........Send NETBIOS_ANQ........Multicast
ADD_NAME_RESPONSE.......Send NETBIOS_ANR........UDP(1)
NAME_IN_CONFLICT........Send DATAFRAME..........Multicast
STATUS_QUERY............Send DATAFRAME..........Multicast(4)
TERMINATE_TRACE (x07)...Send DATAFRAME..........Multicast
TERMINATE_TRACE (X13)...Send DATAFRAME..........Multicast
DATAGRAM................Send DATAFRAME..........Multicast(4)
DATAGRAM_BROADCAST......Send DATAFRAME..........Multicast
NAME_QUERY..............Send NETBIOS_NQ_ex......Multicast(4)
NAME_RECOGNIZED.........Send NETBIOS_NR_ex......UDP(2) 
STATUS_RESPONSE.........Send DATAFRAME..........Multicast(3,4)

Note 1:
Upon receipt of an ADD_NAME_RESPONSE frame, a NETBIOS_ANR SSP message is 
returned via UDP to the originator of the NETBIOS_ANQ message.

Note 2:
Upon receipt of a NAME_RECOGNIZED frame, a NETBIOS_NR_ex SSP message is 
returned via UDP to the originator of the NETBIOS_NQ_ex frame.  Notice that 
although the NAME_RECOGNIZE frame is sent as an ARE (token ring only) frame, 
and the resultant NETBIOS_NR_ex is sent as a UDP directed response to the SSP 
originating the NETBIOS_NQ_ex.   This is because there is no value in sending 
NETBIOS_NR_ex as a multicast packet in the transport network.  The use of ARE 
transmission in the LAN environment is to accomplish some form of load sharing 
in the source routed LAN environment.  Since no analogous capability exists in 
the (TCP) transport network, it is not necessary to emulate this function 
there.   It is important to note, however, that when converting a received NE
TBIOS_NR_ex to a NAME_RECOGNIZED frame, the SSP sends the NAME_RECOGNIZED frame 
as an ARE frame.  This preserves the source route load sharing in the LAN 
environments on either side of the DLSw transport network.  

All other multicast frames are sent into the transport network using the 
appropriate multicast group address.  
 
Note 3:
As a possible enhancement, STATUS_RESPONSE could be sent as a UDP directed 
response, but only if the STATUS_QUERY is no longer sent as a DATAFRAME. This 
is because the receiving SSP would need to process STATUS_QUERY in a special 
way.   In this scenario an incoming   STATUS_QUERY results in a new NETBIOS_SQ 
SSP message which is multicast to all SSPs in the group.   SSPs receiving this 
message remember the originating SSPs address and STATUS_QUERY correlator.  And 
then upon receipt of a STATUS_RESPONSE, the SSP responds via UDP (using the 
remembered originating SSP address) with a new NETBIOS_SR message to the 
originating SSP.   

Note 4:
NetBIOS Remote Name Directory Support 

As of NetBIOS Version 2.1 and beyond all end stations incorporate Remote Name 
Directory support.  When enabled, this function works to reduce broadcasting 
overhead in the network by implementing a NetBIOS name to LSAP cache in the end 
station.  After an initial broadcast, the sending end station caches the 
appropriate name to LSAP pairing and all subsequent CALL, STATUS, and DATAGRAM 
messages to that name are sent directly rather than broadcast.  In order to 
avoid broadcasting a LAN unicast frame into the transport networks in this case 
(as RFC 1795 current does), SSPs must detect this scenario and determine 
whether to multicast or unicast the frame into the transport network.   Note 
that the following discussion only applies to incoming LAN based: NAME_QUERY, 
DATAGRAM, STATUS_QUERY, and STATUS_RESPONSE frames. 

SSPs can detect the use of RND support by inspecting data link headers of the 
incoming packet.  Unfortunately, however, these headers are somewhat media 
specific.  Thus the conditions for determining whether to multicast or send a 
directed message via UDP are different for each LAN media type.  This paper 
will address Ethernet and Token Ring directly.  Other media types may defined 
later as need arises.

Token Ring:

The receiving SSP must inspect the LLC Destination Address field and look for 
the combination of both a broadcast indicator (as specified in the 
Individual/Group bit) and the NetBIOS Functional Address.  In this case, the 
resultant SSP message should be multicast into the transport network.

With the introduction of RND, it is possible to receive a packet with the 
NetBIOS functional address but the I/G bit set to individual.  In this case the 
frame should be unicast into the transport network via UDP.

Ethernet:

Given the lack of Source Routing support in ethernet environments, it is not 
necessary to inspect the I/G bit specifically.  Therefore, in this case SSPs 
need only check the LLC Destination Address for the NetBIOS (ethernet) 
multicast address.  If the destination address is NetBIOS multicast address, 
then the resultant SSP message should be multicast into the transport network.  
Otherwise, the SSP message should be unicast via UDP. 

Address Resolution

Typical NetBIOS circuit setup using Multicast services is  essentially the same 
as specified in RFC 1795.   The only significant difference is that 
NETBIOS_NQ_ex messages are sent via Multicast IP and the NETBIOS_NR_ex is sent 
via UDP to the SSP originating the NETBIOS_NQ_ex.   Thus the NetBIOS address 
resolution algorithm at an individual SSP would be as follows:

/* Begin */

Check the local cache 
 If found 
  Then do I=1 to retry_count
   Send a UDP based NETBIOS_NQ_ex is to the corresponding SSP 
   If a NETBIOS_NR_ex is received (within a timeout window)
    then normal circuit setup is initiated
  End do   
             
  Else do I=1 to retry_count
   Send a NETBIOS_NQ_ex to the appropriate multicast address
   If a NETBIOS_NR_ex is received (within a timeout window)
          then normal circuit setup is initiated
  End do

/* Otherwise */
Circuit setup fails 

/* End */

Circuit Setup 

Following successful address resolution, a NetBIOS end station typically sends 
a SABM/E frame to initiate a formal LLC2 connection.   Receipt of this message 
results in  normal circuit setup as described in the SNA case.  That is to say 
that the CANUREACH_cs messages etc are sent on a TCP connection to the 
appropriate partner SSP.  If no such TCP connection exists, one is brought up. 

Multicast Reliability and Retries

In the case of NetBIOS, many more packets are being sent via multicast and 
UDP.  Therefore, the exposure to the unreliability of these services is greater 
than that of SNA.    In addition, the retry interval for NetBIOS is 
considerably shorter with the defaults being:  retry interval = 0.5 seconds and 
retry count = 6.   With this in mind, it is recommended that SSPs endeavor to 
do the same thing as SNA namely set the SSP retry interval somewhere between 
the anticipated retry interval and total retry time (retry interval * retry 
count).  

Sequencing 

It is important to note that multicast services and UDP do not provide 
guaranteed packet sequencing like TCP does for RFC 1795.  In a steady state 
network, in order packet delivery can be generally assumed.   But in the 
presence of network outages and topology changes, packets may take alternate 
routes to the destination and arrive out of sequence with respect to their 
original transmission order.    For SNA address resolution this should not be a 
problem given that their is no inherent significance to the order of packets 
being transmitted via multicast and UDP.   

In the case of NetBIOS, in order delivery is not guaranteed in the normal case 
(e.g., LANs).  This is because LAN broadcasting mechanisms suffer the same 
problems of packet sequencing as do wan multicast mechanisms.   But one might 
argue the greater likelihood of topology related changes in the wan environment 
and thus a greater level concern.  The vast majority of NetBIOS UI frames 
(being handled via UDP and Multicast) have correlator values which and do not 
rely upon packet sequencing. 

The only NetBIOS frames of special note would be: DATAGRAM, DATAGRAM_BROADCAST, 
and STATUS_RESPONSE.  In the case of DATAGRAM and DATAGRAM_BROADCAST it is 
generally assumed that datagrams do not provide any guarantee of in order 
packet delivery.  Thus applications utilizing this NetBIOS service are assumed 
to have no dependency on in order packet delivery.   STATUS_RESPONSE can 
actually be sent as a sequence of STATUS_RESPONSE messages.  In cases where 
this occurs, the STATUS_RESPONSE will be exposed to potential out of sequence 
delivery. 

Migration

SSPs which implement these enhancements will indicate their support for 
multicast protocols via the multicast capabilities control vector in their 
capabilities exchange.   In this way, an SSP can tell whether or not a specific 
partner SSP supports multicast.  

Connecting to downlevel nodes

It is assumed that TCP connections to SSPs which do not support multicast 
services are established by some means outside the scope of this paper (i.e., 
non-multicast partner addresses are configured by the customer).   TCP 
connections must be established and maintained to down level nodes in the exact 
same manner as RFC 1795 requires, establishes, and maintains them. 

Communicating with downlevel nodes 

Because downlevel nodes will not receive SSP frames via multicast or UDP 
transmission, these messages must be sent over TCP connections to the downlevel 
nodes.   Therefore, nodes which implement the multicast protocol enhancements 
must keep track of which SSP partners do not support multicast extensions (as 
indicated in the capabilities exchange).  When a given packet is sent out via 
multicast services, it must also be sent over the TCP connection to each 
downlevel node.   And although the multicast service requires periodic 
retransmissions (for reliability reasons), this is not the case with TCP 
connections to downlevel nodes.  Therefore, SSP communications with downlevel 
nodes should not be retried in accordance with the multicast/UDP retry 
recommendations.  Furthermore, communications with downlevel nodes should be in 
exact compliance with RFC 1795 protocols.  

In the case of UDP based messages, UDP is only to be used when destination SSP 
is known to support multicast services.  This knowledge can be obtained from 
previous TCP connections/capabilities exchanges or inferred from a previously 
received multicast or UDP message.   In practice, this should not present a 
problem as UDP messages are only sent in response to a multicast base request 
or for UI frames when the local cache has information correlating the 
destination LSAP with some specific SSP.  In this case, if the SSP is 
downlevel, then there would be a TCP connection to it and it would be known to 
be downlevel.  If it is not downlevel and a TCP connection is in existence, 
then its level is known.  If it is not downlevel and there is not an existing 
TCP connection, then it can be implied to be uplevel (by lack of a TCP 
connection).   It may be prudent, however, to cache the multicast capabilities 
of partner SSPs. 

Note: 
When two uplevel SSPs have a established  TCP connection multicast and UDP 
packets, as defined above, are NOT sent over the TCP connection.  TCP 
connections between uplevel SSPs are only used for reliable (LLC2) circuit 
setup, circuit I-frame data, and circuit takedown.  
SSP Frame Formats

Multicast Capabilities Control Vector

This control vector is carried in the Capabilities Exchange Request.  Like all 
control vectors in this SSP message, it is an LT structure.  LT structures 
consist of a 1 byte length field followed by a 1 byte type field.   The length 
field includes itself as well as the type and data fields.  

Byte Bit  Description
0  0-7  Length, in binary, of the multicast capabilities control      vector

1  0-7  Type:  x8C 

2   0-7  Multicast Version Number: 
A binary numerical representation of the level of multicast services provided.  
The protocols as identified in this document constitute version one.   
Accordingly, x01 is encoded in this field.  Any subsequent version must provide 
the services of all previous versions.

3-4    Reserved 

5-n    Optional Control Vectors: parsed LT if present.          Currently, none 
defined. 

Multicast Packets

SSP frame formats are defined in RFC 1795.  Multicast protocol enhancements do 
not change these formats in any way.  But because the receiver of multicast 
packets may need to respond to the originator, it is important to carry the 
appropriate address of the multicast originator.   In addition, the originator 
may have multiple IP addresses.  For example, a unique IP (non-multicast) 
address, a peer to peer multicast address, and a server multicast address.   
Consequently, SSP frames are encapsulated in a special multicast frame header 
which carries the originators unique IP address and any applicable multicast 
address for responses.  

Byte Bit  Description
0-1    Length, in binary, of the multicast packet

1  0-7  Multicast Version Number: 
A binary value corresponding to the multicast version number indicated in the 
Multicast Capabilities Control Vector of the sender. 

2-5     Originating IP Address:
IP (non-multicast) address of the sending SSP.  Always present (note: we 
probably should make this generic... but I didnt have the time to investigate 
proper frame formats)

6-9    Originating Multicast Address: 
Multicast address of the sending SSP.  The multicast address used should be the 
one associated with the group in question.   Determining group context is 
outside the scope of this document, but the section entitled Multicast Groups 
should provide appropriate context.  One item of note is that when the role 
within a group is either client or server, messages should be sent to the 
opposite role and the originating multicast address should reflect the role 
within the group.

10-n    Encapsulated SSP Frame 

UDP Packets

As mentioned above, SSP frame formats are defined in RFC 1795.  Multicast 
protocol enhancements do not change these formats in any way.  But because the 
receiver of UDP packets may need to respond to the originator, it is important 
to carry the appropriate address of the UDP packet originator. Consequently, 
UDP SSP frames are encapsulated in a special UDP frame header which carries the 
originators unique IP address. 

Byte Bit  Description
0-1    Length, in binary, of the UDP packet

1  0-7  Multicast Version Number: 
A binary value corresponding to the multicast version number indicated in the 
Multicast Capabilities Control Vector of the sender. 

2-5     Originating IP Address:
IP (non-multicast) address of the sending SSP.  Always present (note: we 
probably should make this generic... but I didnt have the time to investigate 
proper frame formats)

6-n    Encapsulated SSP Frame